1. Field of the Invention
This invention relates to a personal computer with an efficient and low-overhead method for achieving a variable resolution of timer accuracy from a periodic timing device for improved computer function and particularly for computer animation sequences.
2. Description of the Related Art
Computer operating systems typically provide a mechanism which allows software to schedule an event to occur at some future time. Just as an alarm clock may be set to ring some minutes in the future, software may set a timer to expire some time in the future. Reference is made herein to a timer as a mechanism which, given a duration, a resolution, and an action, will delay for the specified duration, and after that duration, but before the latest permissible expiration time (duration plus resolution), will initiate an appropriate response for the specified action to be taken. FIG. 1 illustrates the points in time and durations of time which are relevant in the function of a software timer.
In FIG. 1, point-in-time 1 is the time at which a timer is created. A timer is created by the operating system of the computer. The program request to create the timer is accompanied by three parameters of information: (a) the duration of the timer (in some unit of time); (b) the resolution of the timer (in some unit of time); and (c) the action to be initiated by the operating system after the timer duration has passed. Point-in-time 2 is the time at which the timer has expired. The timer action is to be initiated on or after this time 2. Point-in-time 3 is the time by which the timer action must be initiated. The timer action must be initiated on or before this point-in-time 3. The time interval 4 between the point-in-time 1 when the timer is first created by the operating system and the point-in-time 2 when the timer has expired is referred to as the duration of the timer. The time interval 5 between the point-in-time 2 when the timer has expired and the point-in-time 3 when the timer action must be initiated is referred to as the resolution of the timer.
For example, a program may wish to ring a bell for 500 milliseconds (ms) or half a second. This can be achieved by turning the bell on, then starting a timer that will expire in 500 milliseconds. The action taken when the timer expires is to turn off the bell. The result is a bell ringing for half a second.
The resolution, accuracy, or permissible error in the duration of the timer may vary with the task being performed. In the case of ringing a bell, it may not matter whether the bell is turned off in 500 ms or 600 ms, as long as an acoustical sound is made. If the resolution of the timer in the before mentioned example was 100 ms, then it would be permissible for the bell to be turned off anywhere from 500 ms to 600 ms after it was turned on. If the resolution of the timer, in the before mentioned example, was 200 ms, then it would be permissible for the bell to be turned off anywhere from 500 ms to 700 ms after it was turned on.
Often a higher degree of timer accuracy is desired. One example is for that of a computer animation sequence. The animation may be playing at 50 frames per second in order that the viewer perceive a smooth flowing motion. A timer may be set up to expire 50 times per second, that is every 20 ms. When the timer expires, the action is to display the next frame. If the resolution of this timer was 100 ms as in the first bell example, the timer might expire anywhere from 20 ms to 120 ms. With this resolution, the viewer can easily detect a very undesirable, irregular, jerky motion in the animation. A timer resolution of 5 ms may be more appropriate for this circumstance and application. From the above examples, it should be clear that a need for different levels of precision in timer duration is necessary.
There are a variety of methods that might be used on a computer system to implement software timers as described above. One such method is that implemented by the IBM Advanced Interactive Executive (AIX) 3.1 Operating System. The AIX hardware platform contains a hardware device that may be programmed to generate an interrupt at a precise time in the future. The hardware device is programmed to interrupt when the next timer is due to expire. It can be precisely programmed to interrupt at the desired timer expiration time. This hardware device is reprogrammed to the time of the next timer request at each interrupt. This insures that the number of interrupts is less than or equal to the number of timer requests. The capability of this device enables AIX to provide all timers with a very good resolution.
However, in the case of the IBM Operating System 2 (OS/2) operating system, a hardware device which can be precisely programmed to interrupt at a specific time cannot be used. This device cannot be used because its function has already been claimed for use by other operating system functions. These other functions include IBM Disk Operating System (DOS) compatibility, performance monitoring and system trace facilities. There is another device that can be utilized. This specific device is not programmable to interrupt at a precise time in the future. Rather, it is programmable to interrupt at one constant periodic rate. Further, there is a limited number of periodic rates to which this device can be programmed to interrupt.
Therefore, there is a constraint that only a periodically interrupting device is available to provide the function of software timers. Further, there is a constraint that the number of interrupts required to implement software timers be kept to a minimum. It is desirable to keep the number of interrupts at a minimum to reduce operating system overhead.
One might consider that a computer system should anticipate the highest resolution that is necessary, and provide that resolution for all timers. In this manner, the system can satisfy the needs of all timers with a single, best resolution timer. This strategy would indeed work, but might be costly in terms of high system overhead time expended to service a large number of periodic interrupts.
On many computer operating systems, the resolution of the timer provided is dependent on some hardware device. In the IBM OS/2 operating system, the Motorola MC146818 device also named the Real-Time Clock Plus RAM, or its functional equivalent, is used to provide software timers. This device can be programmed to generate periodic interrupts from a limited selection of periodic rates. This device is provided in IBM Personal Computer Advanced Technology (IBM-PC AT) hardware architectures, and is also provided in all IBM Personal System 2 (PS/2) hardware architectures. It is this device that the invention method utilizes to provide variable resolution timers with minimal interrupts.
There is an inverse relationship between the frequency of the interrupts and the length of the interval between the interrupts. The resolution of the timers provided can only be as precise as the interval between interrupts. If the interrupts are occurring 10 times per second, a 100 ms resolution timer can be provided. If the interrupts are occurring 50 times per second, a 20 ms resolution can be provided. Unfortunately, as the frequency of the interrupts increases, the overhead, i.e., the time consumed by the system to service all of these interrupts increases proportionally. If the frequency of the interrupts generated by the hardware device triples, the overhead to the operating system of servicing these interrupts also triples. This presents a situation where there is a classical trade-off between improving one desirable attribute (i.e., timer resolution), but only at the sacrifice of another desirable attribute (i.e., low system overhead). A single, best resolution timer requires a constantly high periodic interrupt rate which is costly in terms of system overhead time.
Tests on an IBM PS/2 Model 80 computer indicate that an overhead of 2% of all system cpu time can be consumed by a periodic interrupt occurring at 32 times per second (Hertz or Hz). If the rate is quadrupled to 128 times per second, the overhead quadruples to 8%. Consuming 8% of all available cpu power to service periodic interrupts is very undesirable. This undesirable overhead aspect only gets worse if the interrupt rate is increased.
With this analysis, one might observe that a periodic interrupting device may not be the most appropriate device to use for implementing variable resolution timers. Indeed, as is noted above with AIX 3.1, another device can be used to implement high resolution timers within overhead constraints. However, given the constraint that this device is unavailable for use, a periodic interrupting device may be the only alternative.